查看原文
其他

并发的核心:CAS 是什么?Java8是如何优化 CAS 的?

帅地 苦逼的码农 2019-05-25

大家可能都听说说 Java 中的并发包,如果想要读懂 Java 中的并发包,其核心就是要先读懂 CAS 机制,因为 CAS 可以说是并发包的底层实现原理。

今天就带大家读懂 CAS 是如何保证操作的原子性的,以及 Java8 对 CAS 进行了哪些优化。

synchronized:大材小用

我们先来看几行代码:

public class CASTest {
    static int i = 0;

    public static void increment() {
        i++;
    }
}

假如有100个线程同时调用 increment() 方法对 i 进行自增操作,i 的结果会是 100 吗?

学会多线程的同学应该都知道,这个方法是线程不安全的,由于 i++ 不是一个原子操作,所以是很难得到 100 的。

这里稍微解释下为啥会得不到 100(知道的可直接跳过), i++ 这个操作,计算机需要分成三步来执行。
1、读取 i 的值。
2、把 i 加 1.
3、把 最终 i 的结果写入内存之中。

所以,(1)、假如线程 A 读取了 i 的值为 i = 0,(2)、这个时候线程 B 也读取了 i 的值 i = 0。(3)、接着 A把 i 加 1,然后写入内存,此时 i = 1。(4)、紧接着,B也把 i 加 1,此时线程B中的 i = 1,然后线程 B 把 i 写入内存,此时内存中的 i = 1。也就是说,线程 A, B 都对 i 进行了自增,但最终的结果却是 1,不是 2.

那该怎么办呢?解决的策略一般都是给这个方法加个锁,如下

public class CASTest {
    static int i = 0;

    public synchronized static void increment() {
        i++;
    }
}

加了 synchronized 之后,就最多只能有一个线程能够进入这个 increment() 方法了。这样,就不会出现线程不安全了。不懂 synchronized 的可以看我这篇文章:彻底搞懂synchronized(从偏向锁到重量级锁)

然而,一个简简单单的自增操作,就加了 synchronized 进行同步,好像有点大材小用的感觉,加了 synchronized 关键词之后,当有很多线程去竞争 increment 这个方法的时候,拿不到锁的方法是会被阻塞在方法外面的,最后再来唤醒他们,而阻塞/唤醒这些操作,是非常消耗时间的。

这里可能有人会说,synchronized 到了JDK1.6之后不是做了很多优化吗?是的,确实做了很多优化,增加了偏向锁、轻量级锁等,  但是,就算增加了这些,当很多线程来竞争的时候,开销依然很多,不信你看我另外一篇文章的介绍:彻底搞懂synchronized(从偏向锁到重量级锁)

CAS :这种小事交给我

那有没有其他方法来代替 synchronized 对方法的加锁,并且保证 increment() 方法是线程安全呢?

大家看一下,如果我采用下面这种方式,能否保证 increment 是线程安全的呢?步骤如下:

1、线程从内存中读取 i 的值,假如此时 i 的值为 0,我们把这个值称为 k 吧,即此时 k = 0。

2、令 j = k + 1。

3、用 k 的值与内存中i的值相比,如果相等,这意味着没有其他线程修改过 i 的值,我们就把 j(此时为1) 的值写入内存;如果不相等(意味着i的值被其他线程修改过),我们就不把j的值写入内存,而是重新跳回步骤 1,继续这三个操作。

翻译成代码的话就是这样:

public static void increment() {
    do{
        int k = i;
        int j = k + 1;
    }while (compareAndSet(i, k, j))
}

如果你去模拟一下,就会发现,这样写是线程安全的。

这里可能有人会说,第三步的 compareAndSet 这个操作不仅要读取内存,还干了比较、写入内存等操作,,,这一步本身就是线程不安全的啊?

如果你能想到这个,说明你是真的有去思考、模拟这个过程,不过我想要告诉你的是,这个 compareAndSet 操作,他其实只对应操作系统的一条硬件操作指令,尽管看似有很多操作在里面,但操作系统能够保证他是原子执行的。

对于一条英文单词很长的指令,我们都喜欢用它的简称来称呼他,所以,我们就把 compareAndSet 称为 CAS 吧。

所以,采用 CAS 这种机制的写法也是线程安全的,通过这种方式,可以说是不存在锁的竞争,也不存在阻塞等事情的发生,可以让程序执行的更好。

在 Java 中,也是提供了这种 CAS 的原子类,例如:

  1. AtomicBoolean

  2. AtomicInteger

  3. AtomicLong

  4. AtomicReference

具体如何使用呢?我就以上面那个例子进行改版吧,代码如下:

public class CASTest {
    static AtomicInteger i = new AtomicInteger(0);

    public static void increment() {
        // 自增 1并返回之后的结果
        i.incrementAndGet();
    }
}

CAS:谁偷偷更改了我的值

虽然这种 CAS 的机制能够保证increment() 方法,但依然有一些问题,例如,当线程A即将要执行第三步的时候,线程 B 把 i 的值加1,之后又马上把 i 的值减 1,然后,线程 A 执行第三步,这个时候线程 A 是认为并没有人修改过 i 的值,因为 i 的值并没有发生改变。而这,就是我们平常说的ABA问题

对于基本类型的值来说,这种把数字改变了在改回原来的值是没有太大影响的,但如果是对于引用类型的话,就会产生很大的影响了。

来个版本控制吧

为了解决这个 ABA 的问题,我们可以引入版本控制,例如,每次有线程修改了引用的值,就会进行版本的更新,虽然两个线程持有相同的引用,但他们的版本不同,这样,我们就可以预防 ABA 问题了。Java 中提供了 AtomicStampedReference 这个类,就可以进行版本控制了。

Java8 对 CAS 的优化。

由于采用这种 CAS 机制是没有对方法进行加锁的,所以,所有的线程都可以进入 increment() 这个方法,假如进入这个方法的线程太多,就会出现一个问题:每次有线程要执行第三个步骤的时候,i 的值老是被修改了,所以线程又到回到第一步继续重头再来。

而这就会导致一个问题:由于线程太密集了,太多人想要修改 i 的值了,进而大部分人都会修改不成功,白白着在那里循环消耗资源。

为了解决这个问题,Java8 引入了一个 cell[] 数组,它的工作机制是这样的:假如有 5 个线程要对 i  进行自增操作,由于 5 个线程的话,不是很多,起冲突的几率较小,那就让他们按照以往正常的那样,采用 CAS 来自增吧。

但是,如果有 100 个线程要对 i 进行自增操作的话,这个时候,冲突就会大大增加,系统就会把这些线程分配到不同的 cell 数组元素去,假如 cell[10] 有 10 个元素吧,且元素的初始化值为 0,那么系统就会把 100 个线程分成 10 组,每一组对 cell 数组其中的一个元素做自增操作,这样到最后,cell 数组 10 个元素的值都为 10,系统在把这 10 个元素的值进行汇总,进而得到 100,二这,就等价于 100 个线程对 i 进行了 100 次自增操作。

当然,我这里只是举个例子来说明 Java8 对 CAS 优化的大致原理,具体的大家有兴趣可以去看源码,或者去搜索对应的文章哦。

总结

理解 CAS 的原理还是非常重要的,它是 AQS 的基石,而 AQS 又是并发框架的基石,接下来有时间的话,还会写一篇 AQS 的文章。

推荐阅读:

面试挂在了 LRU 缓存算法设计上

我把留言板带回来了!(内附4重大礼哦)

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存